Add Users

The fields required to setup a user changes based on the authentication provider chosen. The following explains these settings for the different providers.

  • Click here to see details on how to bulk import users.

Note: The details below can be used to navigate the "edit user" process as well.

Add a User

To Add a user, click one of the macro buttons in the top right hand corner:

  • Add Pro User - to add a user with a Pro license
  • Add Viewer User - to add a user with a Viewer license

The add user panel below will open to add a new user into the system. The form presented is different on the authentication provider.

Internal (Database) Authentication

As described, configure the common settings: Admin Type, Tenant and Profile

  • Enter the following user information:
    • User Name: the user's username. This is the LOGIN id of the user. Required.
    • Password: the user's password. Required.
    • Email: the user's email address. Required.
    • First Name: the user's first name. Required.
    • Last Name: the user's last name. Required.
    • Proxy Account 1: the field is used to inject an alternative account name to be used with alternative system authentications. For example, the user's Active Directory account needed for Microsoft SSAS authentication, or the user's SAP BW login for onward connection in other Single Sign On environments (e.g. Azure / Snowflake). Optional.
    • Proxy Account 2: the field is used to inject an alternative account name to be used with alternative system authentications. For example, the user's Active Directory account needed for Microsoft SSAS authentication, or the user's SAP BW login for onward connection in other Single Sign On environments (e.g. Azure / Snowflake). Optional.
    • Phone: the user's phone number (optional). If a phone number is added, it should be formatted with it's international prefix. Optional.

SAML Authentication

As described, configure the common settings: Admin Type, Tenant and Profile

  • Enter the following user information:
    • User Name: the user's username. Required.
      • This is the NOT the official login ID of the user since they will be using SAML. However, the SAML account needs to be associated with an internal username.
    • Password: the user's password. Required.
      • This is the NOT the official password of the user since they will be using SAML. However, the password (which can and should be kept secret) can be used by admins to login to the user's account using the internal password with the internal username.
    • Email: the user's email address. Required.
    • Principal Name: the user's SAML user account name. Required.
      • This is the master key to matching up the SAML token with the user account in Pyramid.
    • First Name: the user's first name. Required.
    • Last Name: the user's last name. Required.
    • Proxy Account 1: the field is used to inject an alternative account name to be used with alternative system authentications. For example, the user's Active Directory account needed for Microsoft SSAS authentication, or the user's SAP BW login for onward connection in other Single Sign On environments (e.g. Azure / Snowflake). Optional.
    • Proxy Account 2:the field is used to inject an alternative account name to be used with alternative system authentications. For example, the user's Active Directory account needed for Microsoft SSAS authentication, or the user's SAP BW login for onward connection in other Single Sign On environments (e.g. Azure / Snowflake). Optional.
    • Phone: the user's phone number (optional). If a phone number is added, it should be formatted with it's international prefix. Optional.

Active Directory Authentication

The Active Directory add process starts with a form to SEARCH for an existing user in the attached Active Directory.

In the search bar:

  • Select a domain that the user belongs to from the drop down
  • Enter a search string
  • Decide if you are searching users (username) or searching groups (group name)
  • Select the appropriate search operation

Click the search button to show the results in the grid below. Select the one or more users to add into the system either by clicking the plus signs or using the check boxes for bulk selections.

In the last panel "User Settings" make the common selections (which will apply to all the chosen users)

  • Admin Type: (Pro Users only) assign the user(s) to the required admin type.
  • Tenant: assign the user(s) to the required tenant.
  • Profile: (Pro Users only) assign the user(s) to the required user profile.

Click Continue to Edit Roles to go to the Edit Roles panel and assign the selected user(s) to the relevant role(s).

Settings Roles

optionally, after inputting the details for the new user(s), click the "Edit Roles" tab to configure and set roles for the newly added user(s).

  • Click the blue plus signs to add a roles for the user (into the right hand grid).
  • Use the check boxes to bulk assign roles instead.

Save

Click the green save button to add the user(s) to the system.

Edit a User

To edit an existing user, click on the user from the Users list; the Edit User panel will open. The settings match are the same as the Add process described above.

When editing a user, there are also several security-based operations available. See below for more.

User Settings

Common Settings

  • User Type: select Professional or Viewer.
  • Admin Type: if the user type is set to Professional.
  • Tenant: select whichever tenant the user should be assigned to.
  • Profile: select the user profile that will be used for the user's experience (Pro, non admin users only)

Other Settings

For Database and SAML systems, all fields can be edited for the user.

For Active Directory most fields are locked, since they were imported from the AD. If corrections needs to be made, the changes should be made int eh AD and then synchronized into Pyramid.

Extra Settings

Secondary Phone: the phone number in the "Phone" field is the value in the Active Directory. Another phone number may be added in the "Secondary Phone" field; in this case, the secondary phone number will override the phone number imported from the Active Directory. The given phone number must be formatted with its international prefix.

User Security Operations

Admins have several user-centric security operations at their disposal when they open a user's configuration card. Some of these options may only apply depending on the chosen authentication provider and / or authentication method.

User Impersonation

The Impersonate capability allows admins to impersonate a user's account and login to the application as that user. By clicking on the Impersonate button, the admin is re-logged in to the application as that user - showing all the rights, capabilities, settings and access.

To exit the impersonation, the admin should formally log out of the application and then re-login as themselves as normal.

Note: user impersonation is available with an Enterprise license only.

Multi-Factor Authentication Token Reset

If Pyramid's internal Multi-Factor Authentication has been enabled, this button is available for admins to clear any authentication tokens that may have been set for a given user. This capability is useful if the user has somehow lost their settings on their authentication device.

Once cleared, the user will be auto-prompted to reset their authenticator token at their next login.

Force Password Reset

When using Pyramid's internal (database) authentication provider, this button allows admins to force a user to reset their password on their next login to the system. Working with this feature is the option to set the minimum password strength for all new passwords. There is also an option to automatically force a password reset for each and every user on the chosen time-cadence.

Revoke Access Cookie

This button revokes all existing and current sessions on Pyramid for the selected user. The user is then forced to re-login to the application. This powerful capability allows admins to resolve different access scenarios. For example:

  • A user's details have changed (roles, license type, tenant, admin access) , and admins want those changes to take immediate effect - they can revoke the access cookie.
  • If admins want to disable a user's access, they can revoke the access cookie to revoke system access.
  • If an admin wants to reset the MFA token, they can revoke access to force the user to re-enroll in the MFA.
  • If the admin wants a user to reset their password, they can revoke access and force the user to supply a new password (when used in tandem with the force password reset).